Field of the Invention
The present application relates to data processing. In particular, but not exclusively, the present application relates to processing data in a packet-switched network.
Description of the Related Technology
FIG. 1 shows a known packet-switched network 100, for example an Internet Protocol (IP) network. Network 100 contains a number of devices which operate an IP (for example IP version 4 (IPv4) or IP version 6 (IPv6)), in this example, device 104 and device 106. Devices such as device 104 and device 106 may be referred to as ‘IP-speakers’ as they operate (or ‘speak’) an IP in the network. Devices 104 and 106 may for example comprise network nodes such as routers or endpoint devices such as user terminals. Network 100 also contains a device 102, for example a Layer 2 (L2) switch, located between device 104 and device 106.
It is common to use a L2 switch such as device 102 to allow multiple IP-speakers to be connected together, for example devices 104, 106, 108 and 110 as shown in packet-switched network 200 depicted in FIG. 2. L2 switch 102 facilitates the IP connection between IP-speaker devices 104, 106, 108 and 110, by forwarding packets between IP-speaker devices 104, 106, 108 and 110 accordingly, whilst remaining ‘invisible’ to IP-speaker devices 104, 106, 108 and 110. By ‘invisible’ here it is meant that devices 104, 106, 108 and 110 are not aware of the existence of L2 switch 102 from an IP perspective. To do this, L2 switch 102 will examine the L2 header at the top of packets it receives.
A packet which L2 switch 102 receives will contain a source media access control (MAC) address which refers to the connected IP-speaking device (for example device 106) that originates the packet. The destination MAC address is the connected IP-speaking device (for example device 104) that the packet should be passed to by device 102. For most data flows, L2 switch 102 does not alter the packet flowing through it, but uses the data in the L2 header to decide where to send the packet. L2 switch 102 may store information from this L2 header for use in future packet forwarding decisions.
To make its forwarding decision, L2 switch 102 does not need to examine the IP header (located at Layer 3 (L3), or ‘IP layer’) which is located underneath the L2 header. Therefore, it is not required that L2 switch 102 knows the IP addresses of the IP-speakers connected to it. By ‘connected to’ here, it is meant directly connected to without any other devices in-between.
The source and destination IP addresses in a packet do not refer to the connected IP-speakers, but the ultimate source and ultimate destination of the packet. A packet may pass through multiple IP-speaking devices on its journey from the source to the destination. Therefore, L2 switch 102 cannot easily determine the IP addresses of its connected IP-speakers from the packets passing through it.
Existing methods for learning addressing information are unsuitable for various reasons, for example because they:
provide L2 information given L3 information (for example using the Address Resolution Protocol (ARP));
provide L3 information given a hostname (for example using the domain name system (DNS) lookup);
assume things about the network as a whole, and do not provide ‘invisibility’ at L3 required of a L2 switch (for example using the Open Shortest Path First (OSPF) protocol, the Intermediate System to Intermediate System (IS-IS) protocol, and/or the Routing Information Protocol (RIP)); or
require the querier (i.e. the device that wants to learn the IP addresses of its connected IP-speakers) to be an IP-speaker (for example using OSPF, the Border Gateway Protocol (BGP), and/or RIP).
A sufficiently advanced L2 switch may want to know L3 information such as IP addresses of the IP-speakers directly connected to it, so that it can provide extra function. However, it is not expected that a network administrator should have to configure such information on a L2 switch. Therefore, it would be desirable for a L2 switch to be able to learn the L3 information such as IP addresses of its connected IP-speakers itself, including doing so whilst maintaining ‘invisibility’ at the IP layer.